Remarks 



Reconsideration and allowance of all claims are respectfully requested. Claims 1-11 
remain pending. 

By this paper, independent claims 1, 5, 9 & 10 are amended to more clearly recite 
Applicant's process of automatically responding to failure of a computing node functioning as 
multicast routing node. In Applicant's technique, the entire node functioning as the multicast 
routing node fails. Support for this amendment can be found throughout the application as filed. 
For example, reference paragraph [0030]. Additionally, dependent claims 2 & 6 are amended to 
clarify that the failure of the computing node is failure of a group leader node and that there is 
automatic selection of a new group leader from functioning computing nodes of the respective 
group having the failed group leader. No new matter is added to the application by any 
amendment presented. 

In the Office Action, claims 1, 5, 9, 10 & 1 1 were rejected under 35 U.S.C. § 102(e) as 
being anticipated by Latif et al. (U.S. Patent No. 6,393,483 Bl; hereinafter "Latif ); while claims 
2-4 & 6-8 were rejected under 35 U.S.C. § 103(a) as being unpatentable over Latif in view of Lim 
et al. (U.S. Patent No. 5,938,732; hereinafter "Lim"). These rejections are respectfully, but most 
strenuously, traversed, and reconsideration thereof is requested. 

In accordance with Applicant's invention (recited, for example, in claim 1), a distributed 
computing environment is set forth having multiple networks of computing nodes which employ 
multicast messaging. At least one node of the multiple networks functions as a multicast routing 
node. The term "multicast messaging" refers to a specific messaging protocol which is distinct 
from standard internet protocol routing. A "multicast routing node" refers to a particular type of 
node performing particular functions associated with multicast messaging. As known in the art, 
multicast messaging is a particular communication protocol wherein one sender sends a single 
message to many receivers. 

In accordance with Applicant's invention, processing is recited which includes: 
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• Automatically responding to failure of a computing node 
functioning as multicast routing node of said at least one computing 
node functioning as said multicast routing node to reassign said 
multicast routing function; and 

• Wherein the automatically responding includes dynamically 
reconfiguring the distributed computing environment to replace 
each failed multicast routing node of said at least one multicast 
routing node with another computing node of the multiple networks 
of computing nodes to maintain multicast message reachability to 
all functional computing nodes of the distributed computing 
environment 

Applicant respectfully submits that both the environment and the process recited in his 
independent claims clearly distinguish the recited subject matter from the teachings of Latif & 
Lim, taken alone or in combination. 

It is well settled that there is no anticipation of a claim unless a single prior art reference 
discloses: (1) all the same elements of the claimed invention; (2) found in the same situation as 
the claimed invention; (3) united in the same way as the claimed invention; and (4) in order to 
perform the identical function as the claimed invention. In this instance, Latif fails to disclose 
various aspects of Applicant's invention as recited in the independent claims presented, and as a 
result, does not anticipate (or even render obvious) Applicant's invention. 

Latif discloses a process for driving a network interface card. The process includes 
monitoring the status of a plurality of ports connected between a computer and a network. 
Detecting a failure in one of the plurality of ports connected to the network. Reassigning data 
transmitted over the failed port to an active port of the plurality of ports selected in a round robin 
technique. The process further includes receiving data over one of the ports designated as a 
primary receiving port. When the failed one of the plurality of ports is the primary receiving 
port, the receiving tasks are assigned to a next active port selected in a round robin technique. 
(See Abstract of Latif.) 
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Initially, Applicant respectfully submits that the Office Action does not state a prima 
facie case of anticipation against claims 1, 5, 9, 10 & 11 by citing Latif A careful reading of 
Latif, and in particular, FIG. 2 & column 5, lines 10-67, column 7, lines 1-55 & column 11, lines 
21-45, fails to uncover any discussion in Latif of the environment recited by Applicant in the 
claims at issue. Specifically, Applicant recites a distributed computing environment wherein 
there are multiple networks of computing nodes which employ multicast messaging. There is no 
discussion in Latif of multicast messaging per se^ which as noted above, is a particular type of 
messaging protocol distinct from standard internet protocol. Further, Applicant's claims recite 
that one of the nodes in at least one of the networks functions as a multicast routing node. A 
multicast routing node is a particular node having multicast routing functionality, as recited in 
the claims. No multicast routing functionality is described in Latif, nor in the Office Action. As 
such, Applicant respectfully submits that the Office Action fails to state a prima facie case of 
anticipation against the claims at issue. 

Further, Applicant respectfully submits that a careful reading of Latif fails to uncover any 
discussion of an automatic response to failure of a computing node functioning as multicast 
routing node. As noted above, there is no node functioning as multicast routing node in Latif In 
addition, there is no failure of a computing node per se described in Latif. Rather, Latif 
describes failure of a network interface card (NIC) within a host or server. The host/server 
equates to a node in one of the networks. Since the server itself does not fail, but rather only a 
component of the server fails, i.e., the intemet RIC card, the teachings of Latif do not equate to 
Applicant's recited process (wherein there is a failure of the computing node itself). As such, 
there can be no automatically responding to failure of a computing node per se, let alone to 
automatically responding to the failure of a computing node that functions as a multicast routing 
node. 

Still further, Applicant recites that the automatically responding includes dynamically 
reconfiguring the distributed computing environment to replace each failed multicast routing 
node. Since there is no nodal failure in LsAif, per se (but rather only failure of a component of a 
node), it is respectfully submitted that there is no automatic reconfiguration of the distributed 
computing environment needed to replace a failed node, let alone a failed multicast routing node. 
Applicant's independent claims each recite that the dynamic reconfiguration replaces the failed 
node having the multicast routing function with a new node so as to maintain multicast 
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reachability to ail functional computing nodes of the environment. Again, no such facility is 
taught or suggested by Latif 

To summarize, Latif does not describe failure of a node per se within a distributed 
computing environment, but rather failure of a port (NCI card). As such, Latif cannot teach or 
suggest a process for automatically responding to failure of a node, let alone responding by the 
dynamic reconfiguration of the distributed computing environment to transfer multicast routing 
functionality as recited in Applicant's independent claims. 

Further, there is no discussion of multicast messaging per se, let alone the provision of 
multicast routing functionality at a particular node, nor of a facility for automatically responding 
to failure of the node having the multicast routing functionality to automatically transfer that 
functionality to another node of the network of the distributed computing environment. 
Multicast messaging and multicast routing functionality are known terms and refer to a particular 
type of messaging protocol. This messaging protocol is not taught by Latif, and as such, there 
can be no anticipation of Applicant's invention based on Latif. 

For at least the above reasons, Applicant respectfully submits that the independent claims 
patentably distinguish over the applied art. Reconsideration and withdrawal of the rejection to 
these claims is therefore requested. 

The dependent claims are believed allowable for the same reasons as the independent 
claims, as well as for their own additional characterizations. Regarding the art cited in 
connection with the obviousness rejection to dependent claims 2-4 & 6-8, Applicant respectfully 
submits that there is no discussion of multicast messaging per se in Lim, thus there is no 
discussion of a multicast routing node per se. As noted above, multicast messaging is a 
particular type of messaging protocol that is not discussed in either of the applied patents. 

Further, it is respectfully submitted that Lim describes a single multiprocessor machine 
and not nodes in a network. Thus, the discussion in Lim of processing groups and a leader of a 
group refers to a multiprocessor machine, which is clearly a distinct environment from that 
recited by Applicant. Further, numerous aspects of Applicant's invention as recited in dependent 
claims 2-4 & 6-8 are simply not taught or suggested by Lim, alone or in combination with Latif. 
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For example, Applicant recites that each group leader is coupled by a virtual interface to 
at least one other group leader of the computing nodes. The term "virtual interface" is a term of 
art that is associated with protocol encapsulation. A careful reading of Lim fails to uncover any 
discussion of the creation or maintenance of a virtual interface. Further, Applicant's claims 2 & 
6 recite that the failure occurs at a group leader node and that there is automatic selection of a 
new group leader from functioning computing nodes of the respective group of computing nodes 
having the group leader failure. No similar functionality is taught or suggested by Lim. In Lim, 
the group leader identifies failure of a host of a group of hosts, but there is no discussion of 
failure at the leader . Applicant recites a fimctionality specifically directed to the situation where 
the group leader node, having the multicast routing functionality, fails. No similar situation is 
addressed by the teachings of Lim. 

Still further, dependent claims 3 & 7 recite that the virtual interface is a multicast 
messaging tunnel between group leaders. A careful reading of Lim, and in particular, FIG. 1 A, 
item 20, as well as column 8, lines 39-65 cited in the Office Action, fails to uncover any 
discussion relevant to this aspect of Applicant's invention. There is simply no discussion of a 
virtual interface comprising a multicast messaging tunnel between group leaders in Lim. 
Further, there is no discussion in either Lim or Latif that the multicast messaging tunnel is 
established using a particular daemon, that is, an m-routed daemon. An m-routed daemon, as 
used in the present application, refers to a multicast routing daemon. There is no discussion of 
multicasting per se in Latif or Lim, and as such, there is clearly no discussion of an m-routed 
daemon. 

For at least the above reasons, all claims are believed to be in condition for allowance and 
such action is respectfully requested. 



POU919980019US2 



-12- 



If a telephone conference would be of assistance in advancing prosecution of the subject 
application, Applicant's undersigned attorney invites the Examiner to telephone him at the 
number provided. 



Dated: January )0 , 2006. 

HESLIN ROTHENBERG FARLEY & MESITI P.C. 

5 Columbia Circle 

Albany, New York 1 2203-5 1 60 

Telephone: (518)452-5600 

Facsimile: (518)452-5579 



Respectfully submitted, 




Kevin P. Radigan ([j 
Attorney for Applicant 
Registration No.: 31,789 
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